OBJECT statement

Purpose

Communicate with a COM object through the dispatch interface.

Syntax

OBJECT GET interface.member[.member.] [([[paramname =] param1 [, ...]])] TO ResultVar

OBJECT LET interface.member[.member.] [([[paramname =] param1 [, ...]])] = ValueVar

OBJECT SET interface.member[.member.] [([[paramname =] param1 [, ...]])] = ValueVar

OBJECT CALL interface.member[.member.] [([[paramname =] param1 [, ...]])] [TO ResultVar]

OBJECT RAISEEVENT [interface.]member[([[paramname =] param1 [, ...]])]

Remarks

There are five general forms of the OBJECT statement which are used to communicate through a Dispatch interface to an object.

OBJECT GET	Retrieve or read the value of an Interface member Property. This is similar to retrieving the value of a variable.
OBJECT LET	Assign or write a value to an Interface member Property. This is similar to assigning a value to a variable.
OBJECT SET	Assign or write a value to an Interface member Property that contains a reference to an object. For example, a reference to another Interface.
OBJECT CALL	Call or execute a member Method of an Interface. This is equivalent to calling a Sub or Function.
OBJECT RAISEEVENT	Call or execute a member Method of a Dispatch event Interface. Because the Dispatch event interface is pre-defined, you are not required to specify the interface name in this form of the statement. However, including it aids in self-documentation of your program. If your program is using a Direct, V-Table event handler you should use the RAISEEVENT statement instead. See the EVENT SOURCE statement for an OBJECT RAISEEVENT example.

All parameters, return values, and assignment values must be in the form of COM-compatible variables. Literals and expressions are not allowed. COM-compatible variables include BYTE, WORD, DWORD, INTEGER, LONG, QUAD, SINGLE, DOUBLE, CURRENCY, POINTER, and VARIANT. You should use caution passing string data since COM Objects require that unicode format be used. When string data is contained in a VARIANT variable, conversion to/from unicode is automatic, and no intervention is needed from the programmer. However, if you pass data in a dynamic string variable, you must use the ACODE$() and UCODE$() functions to convert the data to an appropriate format. For this reason, we recommend that string data be passed using VARIANT variables.

Dispatch OBJECT Method calls may be bound at run-time using late binding, which requires no declaration of Properties and Methods. However, for this very reason, the validity of these references can not be verified by PowerBASIC at the time the program is compiled.

The OBJECT statement can use both positional and named parameters, but you should keep in mind that not all COM Dispatch Servers support named parameters. Positional parameters are universally supported.

A positional parameter is simply a variable containing an appropriate value. It is identified by its position in the parameter list, just as in a traditional SUB or FUNCTION. A named parameter consists of a parameter identifier (a name), an equal (=) sign, and a variable containing an appropriate value. Positional parameters must precede any and all named parameters, but named parameters may be specified in any sequence.

Each time you call a Method or Property using the OBJECT statement, a status code is returned in a hidden parameter to indicate the success or failure of the operation. You can retrieve information about this status code with the OBJRESULT function, and also by using the IDISPINFO Dispatch Information Object. If the failure was severe, then a PowerBASIC error 99 (Object Error) is also generated and the ERR system variable is set. You can find more information about these items by referring to OBJRESULT, IDISPINFO, and ERR. This information can be very useful for both debugging and handling run-time errors.

Restrictions

All parameters, return values, and assignment values must be in the form of COM-compatible variables. Use of the wrong member mode (GET/LET/SET/CALL/RAISEEVENT) can sometimes result in unexpected and fatal run-time errors. So, it's usually prudent to test the result code in OBJRESULT after every OBJECT statement.